클로드 코드 완벽 가이드 — 12장 PRD와 실행 계획하기 딥다이브 학습 노트

출처: 클로드 코드 완벽 가이드 (코드팩토리 최지호) | 참고: https://github.com/codefactory-co

12장에서 다루는 내용

• PRD(Product Requirements Document)란? — 무엇을, 왜 만드는지를 정의하는 제품 요구사항 정의서
• 실행 계획(Execution Plan)이란? — PRD를 구현하기 위해 어떻게, 언제까지 만들지를 정의하는 기술 문서
• PRD와 실행 계획의 차이점 — 전략(숲) vs 전술(나무), What/Why vs How/When
• PRD 작성법 — 필수 4항목 + 추가 2항목, 클로드 코드를 활용한 2단계 프로세스
• 실행 계획 작성법 — 작업 분해 → 기술 명세 → 의존성 파악 → 산출물·일정, 커스텀 커맨드 활용

전체 흐름도

┌─────────────────────────────────────────────────────────┐
│           좋은 코드는 키보드가 아닌 좋은 계획에서 시작된다      │
└─────────────────────────────────────────────────────────┘
        │
        ▼
┌───────────────────────────────────────────────────────┐
│  PRD (Product Requirements Document)                  │
│  = 제품 요구사항 정의서                                   │
│                                                        │
│  핵심 질문: 무엇을(What) 왜(Why) 만드는가?               │
│  ┌──────────────────────────────────────────┐         │
│  │ 1. 문제 정의        → 해결할 문제 명확화     │         │
│  │ 2. 타깃 사용자      → 누가, 어떤 상황에서   │         │
│  │ 3. 제안 해결책      → 핵심 솔루션 간결 설명  │         │
│  │ 4. 목표·성공 지표   → 수치화된 KPI 설정     │         │
│  │ 5. 핵심 사용자 흐름 → 주요 시나리오 정의     │         │
│  │ + 경쟁사 분석, MVP 요구사항                  │         │
│  └──────────────────────────────────────────┘         │
└───────────────────────┬───────────────────────────────┘
                        │
                        ▼
┌───────────────────────────────────────────────────────┐
│  실행 계획 (Execution Plan)                             │
│  = PRD를 구현하기 위한 기술적 액션 플랜                    │
│                                                        │
│  핵심 질문: 어떻게(How) 언제까지(When) 만드는가?          │
│  ┌──────────────────────────────────────────┐         │
│  │ 1. 작업 분해       → 기술적 태스크 쪼개기    │         │
│  │ 2. 기술 명세       → 스택, API, 라이브러리   │         │
│  │ 3. 의존성 파악     → 선행 작업 관계 정리     │         │
│  │ 4. 산출물·일정     → 스프린트, 마감일       │         │
│  └──────────────────────────────────────────┘         │
└───────────────────────┬───────────────────────────────┘
                        │
                        ▼
┌───────────────────────────────────────────────────────┐
│  클로드 코드와 협업                                      │
│                                                        │
│  PRD-instruction.md  ──▶  클로드에게 PRD 작성 요청       │
│       (4가지 범위 정의)     (PM 페르소나 부여)             │
│                                    │                    │
│                                    ▼                    │
│                              PRD.md 생성               │
│                                    │                    │
│                                    ▼                    │
│  execution_plan.md  ──▶  클로드에게 실행 계획 요청        │
│       (커스텀 커맨드)       (태스크 분해 전문가 역할)       │
│                                    │                    │
│                                    ▼                    │
│                         GitHub 이슈 자동 생성             │
│                         (Phase별 Task List)             │
└───────────────────────────────────────────────────────┘

선수 지식 체크리스트

• [ ] 소프트웨어 개발 프로세스 기본 이해 (기획 → 설계 → 개발 → 테스트)
• [ ] 프로젝트 관리 기본 용어 (스프린트, 마일스톤, MVP 등)
• [ ] 클로드 코드 기본 사용법 (프롬프트 작성, 파일 참조)
• [ ] 마크다운 문서 작성 경험
• [ ] GitHub 이슈/프로젝트 보드 사용 경험 (선택)

핵심 키워드

12.1 PRD란?

한 줄 요약

PRD는 '무엇을, 왜 만들어야 하는지'를 정의하는 문서로, 개발자뿐 아니라 기획자·디자이너·마케터 등 모든 이해관계자가 같은 그림을 보게 만드는 핵심 커뮤니케이션 도구이다.

쉬운 설명 (비유로 풀어쓰기)

PRD는 집을 짓기 전에 그리는 설계 도면과 같습니다. 도면 없이 "예쁜 집 지어줘"라고만 하면 건축가마다 다른 집을 상상하겠죠? PRD는 "2층짜리, 방 3개, 남향, 주차장 포함"처럼 모든 사람이 같은 집을 떠올리게 만드는 약속 문서예요.

기술적인 내용(어떤 벽돌을 쓸지, 어떤 공법으로 지을지)이 아니라, 어떤 사용자가 어떤 문제를 겪고 있어서 어떤 집이 필요한지를 명확히 합니다.

실무 예제

PRD가 답해야 할 6가지 핵심 질문:

┌──────────────────────────────────────────┐
│  PRD의 핵심 질문 체크리스트                  │
│                                           │
│  □ 어떤 사용자를 위해 만드는가?             │
│  □ 어떤 문제를 해결해주는가?                │
│  □ 비즈니스 측면에서 어떤 이득이 있는가?    │
│  □ 어떤 기능과 경험을 제공해야 하는가?      │
│  □ 사용자는 어떤 경험을 하게 되는가?        │
│  □ 우리는 무엇을(What), 왜(Why) 만드는가?  │
└──────────────────────────────────────────┘

❌ 나쁜 PRD vs ✅ 좋은 PRD 비교:

❌ 나쁜 PRD:
"로그인 기능이 없어서 만든다"
→ 목적 없는 정의, 수치 없음, 누구를 위한 건지 불분명

✅ 좋은 PRD:
"현재 사용자가 X라는 문제를 겪고 있어
 이탈률이 Y%에 달한다.
 이를 해결하기 위해 Z 기능을 제공하여
 재방문율 15% 상승을 목표로 한다."
→ 문제를 수치로 정의, 해결책과 성공 지표 명확

쇼핑몰 사이트 구축 PRD 예시:

1. 프로젝트명: 소상공인을 위한 간편 쇼핑몰 솔루션

2. 문제 정의(Why):
   많은 소상공인이 온라인 판매를 원하지만,
   웹사이트 제작의 높은 비용과 기술적 복잡성 때문에
   시장 진출에 어려움을 겪고 있다.

3. 목표 및 성공 지표:
   목표: 코딩 지식 없는 소상공인도 몇 시간 안에
         자신만의 온라인 스토어를 개설하고 운영
   성공 지표: 론칭 후 6개월 내 활성 스토어 100개,
             월 거래액 1억 원 달성

4. 핵심 사용자 스토리(What):
   a. 판매자로서, 상품 이미지/설명/가격을 쉽게
      등록하고 재고를 관리할 수 있다.
   b. 구매자로서, 원하는 상품을 쉽게 검색하고,
      장바구니에 담아, 안전하게 결제할 수 있다.
   c. 판매자로서, 주문 내역을 확인하고
      배송 상태를 관리할 수 있다.

5. 핵심 디자인 원칙 및 사용자 흐름(What):
   디자인 원칙: 모바일 우선 접근(Mobile-First)
   핵심 사용자 흐름(구매자):
   메인 페이지 → 상품 검색/발견 → 상품 상세 페이지
   → 장바구니 담기 → 주문/결제 → 결제 완료

핵심 체크포인트

• PRD는 개발자만을 위한 문서가 아님 — 기획자, 디자이너, 마케터 등 모든 이해관계자를 위한 커뮤니케이션 도구
• PRD의 주목적은 구현이 아니라 방향 설정과 이해를 돕는 것
• '기능이 없어서 만든다'가 아니라 '현재 문제가 X이고, Y%에 달하므로 해결한다'처럼 수치화된 문제 정의 필요
• 클로드도 PRD를 통해 사용자의 의도를 잘 파악할 수 있어 더 좋은 답변을 생성

12.2 실행 계획이란?

한 줄 요약

실행 계획은 PRD가 던져준 '무엇을'이라는 질문에 대해 '어떻게(How)', '언제까지(When)' 만들지를 구체적인 기술의 언어로 정리한 문서이다.

쉬운 설명 (비유로 풀어쓰기)

PRD가 "서울에서 부산까지 가자"라는 목적지를 정한 것이라면, 실행 계획은 "KTX를 타고, 서울역에서 오전 10시에 출발하고, 2시간 30분 후 부산역 도착"이라는 구체적인 이동 경로를 짜는 것입니다.

PRD가 꿈을 이야기한다면, 실행 계획은 꿈을 현실로 만드는 방법을 이야기합니다. 어떤 아키텍처를 쓸지, API 명세는 어떻게 할지, 데이터베이스 스키마는 어떻게 설계할지 등 기술적 디테일이 담깁니다.

실무 예제

실행 계획이 답해야 할 5가지 핵심 질문:

┌──────────────────────────────────────────┐
│  실행 계획의 핵심 질문                       │
│                                           │
│  □ 어떤 기술 스택을 사용할 것인가?          │
│  □ 아키텍처를 어떻게 구성할 것인가?         │
│  □ 데이터를 어떤 모델로 저장할 것인가?      │
│  □ 어떤 함수와 클래스를 작성할 것인가?      │
│  □ 어떤 작업을 먼저 수행할 것인가?          │
└──────────────────────────────────────────┘

실행 계획 예시 — 상품 등록 기능:

1. 목표: PRD의 사용자 스토리 '판매자로서, 상품 이미지,
   설명, 가격을 쉽게 등록하고 재고를 관리할 수 있다.'를 구현

2. 기술 명세(How):
   Backend  : Node.js, Express.js, PostgreSQL, Sequelize(ORM)
   Frontend : React, TypeScript, Axios
   Image    : AWS S3

3. 태스크(What, but Technical):
   Task 1 (DB)       : products 테이블 스키마 설계
                        (id, name, description, price, stock, imageUrl)
   Task 2 (Backend)  : POST /api/products API 엔드포인트 개발
   Task 3 (Backend)  : 이미지 업로드 API 및 S3 연동
   Task 4 (Frontend) : 상품 등록 UI 컴포넌트 개발
   Task 5 (Frontend) : 상품 정보 입력 폼 + API 호출 로직

4. 의존성(Order):
   Task 1, 2가 완료되어야 Task 5의 연동 테스트가 가능

AI에게 실행 계획의 의존성이 특히 중요한 이유:

❌ 의존성 없는 실행 계획을 AI에 제공:
   → AI가 프론트엔드부터 만듦
   → 백엔드 API가 없어서 연동 실패
   → 순서가 엉킴, 버그 발생

✅ 의존성이 명확한 실행 계획:
   "Task 1(DB) → Task 2(API) → Task 5(프론트 연동)"
   → AI가 올바른 순서로 작업
   → 병목 없이 진행
   → 독립적 태스크는 동시 개발 가능

핵심 체크포인트

• 실행 계획은 큰 문제를 작고 명확한 해결 가능한 문제로 분해하는 과정
• AI의 대표적 약점인 콘텍스트 크기 한계를 극복하기 위해 태스크를 작게 쪼개는 것이 핵심
• 사람보다 AI 에이전트에게 보여줄 때 의존성 명시가 더욱 중요 (AI는 프로젝트 전후 사정을 모르기 때문)
• 잘 만들어진 실행 계획은 각 목표가 명확하고, 어떤 기술로 어떤 결과물을 도출해낼지 명시

12.3 PRD와 실행 계획의 차이점

한 줄 요약

PRD는 전략(숲)이고 실행 계획은 전술(나무)이다 — PRD가 큰 그림을 그리면, 실행 계획이 기술적 구현법을 정의한다.

쉬운 설명 (비유로 풀어쓰기)

레스토랑을 여는 것에 비유하면: - PRD = "한식 파인다이닝 레스토랑을 열자. 30대 직장인을 타깃으로, 런치 코스 3만원대, 월 매출 5천만원이 목표야." - 실행 계획 = "주방에 인덕션 6구 설치, POS 시스템은 A사 사용, 메뉴 레시피 10종 개발 완료 후 시식회 진행, 오픈 D-30일에 인스타 광고 시작."

둘은 항상 짝이에요. PRD 없이 실행 계획만 세우면 방향을 잃기 쉽고, 실행 계획 없이 PRD만 있으면 실행력이 떨어집니다.

실무 예제

PRD vs 실행 계획 비교표:

┌──────────┬──────────────────────┬──────────────────────────┐
│  구분    │  PRD                 │  실행 계획                │
├──────────┼──────────────────────┼──────────────────────────┤
│  핵심    │  What & Why          │  How & When              │
│          │  (무엇을? 왜?)       │  (어떻게? 언제까지?)      │
├──────────┼──────────────────────┼──────────────────────────┤
│  목적    │  방향 설정, 공감대    │  작업 실행, 진척도 관리    │
├──────────┼──────────────────────┼──────────────────────────┤
│  관점    │  전략 (숲)            │  전술 (나무)              │
├──────────┼──────────────────────┼──────────────────────────┤
│  독자    │  모든 이해관계자      │  개발팀                   │
│          │  (기획·디자인·마케팅) │                           │
├──────────┼──────────────────────┼──────────────────────────┤
│  언어    │  비즈니스·사용자 언어 │  기술·코드 언어            │
├──────────┼──────────────────────┼──────────────────────────┤
│  결과물  │  잘 정의된 문제와 목표│  잘게 쪼개진 Task List    │
└──────────┴──────────────────────┴──────────────────────────┘

클로드 코드 활용 시 각 문서의 역할:

PRD를 참고하면:
  → 클로드가 서비스의 오버뷰 성격(디자인, UX)을 이해
  → 개발자가 의도한 UX를 준수하는 데 큰 도움

실행 계획을 참고하면:
  → 클로드가 기능적인 요소를 정확히 코드로 구현
  → 개발자의 의도를 벗어나는 걸 방지
  → 명시한 기술과 명시한 스펙대로 정확히 개발

핵심 체크포인트

• PRD = "무엇을, 왜" / 실행 계획 = "어떻게, 언제까지"
• PRD는 비즈니스·사용자 관점 / 실행 계획은 기술·개발 관점
• 둘은 항상 짝 — PRD 없이 실행 계획만 세우면 방향을 잃고, 실행 계획 없이 PRD만 있으면 실행력이 떨어짐
• PRD 하나당 반드시 실행 계획 하나일 필요는 없음 — 기술 구현이 10가지라면 10개의 독립적 실행 계획 가능

12.4 PRD 작성법

한 줄 요약

PRD는 문제 정의, 타깃 사용자, 제안 해결책, 목표·성공 지표의 4가지 필수 항목에 경쟁사 분석과 MVP 요구사항을 추가하면 더욱 완성도 높은 문서가 된다.

쉬운 설명 (비유로 풀어쓰기)

PRD 작성은 병원에서 진단서 쓰는 것과 같습니다. "머리가 아파요"(증상)만 적으면 안 되고, "언제부터(문제 정의), 어떤 상황에서(사용자·사례), 어떤 치료를 제안하며(해결책), 치료 후 목표 수치는 어떻게 되는지(성공 지표)"까지 적어야 정확한 처방이 나옵니다.

실무 예제

PRD 필수 4가지 항목 + 추가 2가지:

[필수 항목]

1. 문제 정의
   ❌ "로그인 기능이 없어서 만든다"
   ✅ "현재 사용자가 X라는 문제를 겪고 있어
       이탈률이 Y%에 달한다"
   → 수치와 정확한 정의를 통해 문제를 제시

2. 타깃 사용자 및 사용 사례
   → 핵심 사용자가 누구이고 어떤 상황에서 사용하는지 정의
   → 명확할수록 자신도 서비스에 대해 깊게 이해하게 됨

3. 제안 해결책
   → 문제를 해결하기 위한 솔루션을 짧게 설명
   → 긴 설명이 필요하면 오히려 더 많은 문제를 만들어낼 수 있음

4. 목표 및 성공 지표
   ❌ "로그인 기능 추가" (모호한 목표)
   ✅ "재방문율 15% 상승" (측정 가능한 지표)
   → 전과 후를 비교할 수 있는 명확한 수치

[추가 항목 — 더 완성도 높은 PRD]

5. 경쟁사 분석
   → 다른 서비스가 같은 문제를 어떻게 해결하는지
   → 우리 서비스의 차이점(뭔지)을 추가로 정의

6. MVP 요구사항
   → 최소한의 기능 구현에 대해 정의
   → 사용자 관점에서 서술 (예: 회원가입 → 로그인
     → 프로필 수정 및 조회)

클로드 코드를 활용한 PRD 작성 2단계 프로세스:

[01단계] PRD-instruction.md 작성
─────────────────────────────
개발자가 직접 4가지 범위를 정의:

  # 문제 정의
  오프라인 매장을 운영하는 소상공인 중 약 70%가
  온라인 판매를 원하지만, 기존 쇼핑몰 플랫폼은
  평균 30개 이상의 불필요한 기능과 10%에 달하는
  높은 수수료 때문에 진입 장벽이 매우 높습니다.

  # 타깃 사용자 및 사용 사례
  ## 핵심 사용자
  30~40대 소상공인. SNS는 익숙하지만
  코딩이나 웹사이트 제작 경험은 없는 분들.

  # 제안 해결책
  '올인원 모바일 쇼핑몰' 솔루션을 제공합니다.

  # 목표 및 성공 지표
  소상공인의 온라인 커머스 진입 장벽을 낮춘다.
  성공 지표: 론칭 후 6개월 내 활성 스토어 500개 확보


[02단계] 클로드 코드에게 PRD 작성 요청
─────────────────────────────
프롬프트:
  "너는 이제부터 코드팩토리라는 회사의 PM이야.
   @PRD-instruction.md 파일에 적힌 내용을 기반으로
   PRD를 작성해줘. 결과물을 PRD.md에 저장해주고
   실행계획은 따로 작성할 계획이니
   PRD에서는 서비스에 대한 오버뷰에 집중해줘."

→ 클로드가 자동으로 구조화된 PRD.md를 생성!

PRD 작성 핵심 팁:

💡 PRD를 제작하는 에이전트는 따로 다른 업무를 시키지 않고
   PRD 작업 업무만 시키는 게 좋습니다.

이유:
  → 콘텍스트를 아끼며 서비스의 다른 기능에 대한 PRD를
     작성해달라고 했을 때, 지금까지 나눈 대화의 콘텍스트를
     최대한 활용해서 정확한 PRD를 기능별로 찍어낼 수 있기
     때문입니다.

💡 클로드 코드는 프로젝트 콘텍스트를 이해할 수 있으므로
   UI, DDL, Schema 등 참조할 만한 정보를 미리 작성해두고
   명령을 하면 더욱 상세한 PRD를 받아볼 수 있습니다.

핵심 체크포인트

• PRD 형식이 꼭 정해져 있는 건 아니지만, 4가지 필수 항목(문제 정의, 타깃 사용자, 제안 해결책, 목표·성공 지표)은 반드시 포함
• 짧고 간결하게 작성하되, 내용을 구체화하고 집필하려면 상당한 시간이 필요 → 클로드에게 위임 가능
• PRD-instruction.md에 4가지 범위를 정의 → 클로드에게 PM 페르소나를 부여하여 PRD.md 자동 생성
• PRD 전담 에이전트를 사용하면 콘텍스트를 최대한 활용하여 기능별 정확한 PRD 생산 가능

12.5 실행 계획 작성법

한 줄 요약

실행 계획은 작업 분해 → 기술 명세 → 의존성 파악 → 산출물·일정의 4단계 워크플로로 작성하며, 커스텀 커맨드를 통해 클로드에게 자동으로 상세한 태스크 분해를 요청할 수 있다.

쉬운 설명 (비유로 풀어쓰기)

실행 계획 작성은 요리 레시피를 만드는 과정과 같습니다. "김치찌개를 만든다(PRD)"라는 목표가 정해졌으면, 이제 "1. 재료 준비(돼지고기 200g, 김치 300g) 2. 돼지고기 볶기 3. 물 넣고 끓이기 4. 김치 넣기 5. 간 맞추기"처럼 구체적인 순서와 방법을 쪼개서 적는 거예요.

핵심은 각 단계가 독립적이어야 한다는 것. "재료 준비"를 하면서 동시에 "간 맞추기"를 할 수는 없잖아요?

실무 예제

실행 계획 작성 4단계 워크플로:

1. 작업 분해 (Task Decomposition)
   ─────────────────────────────
   PRD의 사용자 스토리를 가져와서
   이걸 구현하기 위해 필요한 모든 기술적 작업을 나열

   예: "소셜 로그인" 스토리가 있다면
   → 프런트엔드 UI 버튼 제작
   → 백엔드 OAuth 콜백 API 개발
   → User 테이블에 소셜 ID 컬럼 추가
   → 이 과정이 AI에게 프롬프팅하는 것과 완전히 동일!

2. 기술 명세 (Technical Specifications)
   ─────────────────────────────
   각 Task에 대한 구체적인 기술적 결정
   → API의 Request/Response 형태
   → 어떤 라이브러리를 사용할지
   → 에러 처리는 어떻게 할지

3. 의존성 파악 (Dependencies)
   ─────────────────────────────
   벽을 세우기 전에 기초 공사를 해야 하듯,
   작업 간의 선후 관계를 정의
   예: "백엔드 API가 나와야 프런트엔드에서
       연동 테스트를 할 수 있다"

4. 산출물 및 일정 (Timeline)
   ─────────────────────────────
   각 Task가 얼마나 걸릴지 예측하고,
   언제까지 완료할지 현실적인 일정을 세움
   → 하나의 스프린트 계획과 마감일을 정하는 과정

클로드 코드용 실행 계획 커스텀 커맨드 (execution_plan.md):

# 실행 계획 제작 커맨드

너는 지금부터 복잡한 개발 작업을 아규먼트로 받아서
독립적이고 관리 가능한 태스크로 분해하고 실행
계획을 작성하는 실행계획 설계 전문가야.

## 실행
작업은 아래 순서대로 실행해줘.
- 태스크 분석
- 태스크 분해
- 분해된 이슈 출력
- 사용자가 확인할 수 있도록 모든 분해된 이슈를 콘솔에 출력

## 핵심 목적
제시된 개발 태스크를 다음과 같이 변환하기
- 적절하게 태스크 분류 (백엔드/프런트엔드/풀스택/기타)
- 서로 독립적이고 영역을 침범하지 않는 태스크
- 서로에게 의존해야 한다면 "의존성"으로 해당 태스크 등록하기
- 200K 단일 컨텍스트 내에 완료할 수 있는 분량의 태스크

커스텀 커맨드 실행 결과 — 태스크 분석 보고서 예시:

📊 태스크 분석 보고서
────────────────────
태스크 요약
  원본 요청: 온라인 쇼핑몰 웹사이트를 제작하려고
            하는데 해야하는 작업을 Task List로 제작해줘
  주요 타입: Fullstack (모바일 앱 중심)
  총 이슈: 18개
  전체 복잡도: Complex (복합적)
  예상 총 소요 시간: 약 2~3개월 (3~4인 팀 기준)

태스크 분류
  주요 영역: Fullstack (모바일 앱)
  하위 영역:
  □ 데이터베이스 작업    □ UI 컴포넌트
  □ API 엔드포인트      □ 사용자 상호작용
  □ 인증                □ 스타일링
  □ 결제 시스템 연동     □ 푸시 알림

GitHub 이슈 목록
  Phase 1: 프로젝트 기반 및 사용자 인증
  Phase 2: 상품 관리
  Phase 3: 장바구니 및 결제
  ... (총 18개 이슈로 분해)

핵심 체크포인트

• 실행 계획은 기술 명세, 작업, 의존성, 산출물 일정 4가지로 구성
• PRD 하나당 실행 계획 하나가 아닐 수 있음 — 기술 구현 10가지면 10개의 실행 계획 가능
• AI에게 실행 계획을 요청할 때 커스텀 커맨드를 활용하면 작업 분해, 기술 명세, 의존성, 산출물 일정을 자동 생성
• 의존성 명시가 특히 중요 — AI는 프로젝트 전체를 알지 못하므로 선행되어야 하는 작업을 꼭 명시

연습문제

문제 1: PRD 핵심 질문 채우기 (기본)

다음은 "학생 출결 관리 앱" PRD를 작성하려고 합니다. 빈칸을 채워보세요.

1. 문제 정의: 현재 교사들이 ___(a)___ 방식으로 출결을 관리하여
   ___(b)___ 문제가 발생하고 있다.
2. 타깃 사용자: ___(c)___
3. 제안 해결책: ___(d)___
4. 성공 지표: ___(e)___

a. 수기(종이 출석부) — 구체적인 현재 방식
b. 월말 통계 집계에 평균 2시간 소요, 오류율 15% — 수치화된 문제
c. 초·중·고등학교 담임교사 (30~50대, 스마트폰 사용에 익숙)
d. 스마트폰 앱에서 터치 한 번으로 출결을 기록하고,
   자동으로 월별/학기별 통계를 생성하는 솔루션
e. 출결 기록 시간 90% 단축 (2시간 → 10분),
   오류율 15% → 1% 이하로 감소

문제 2: PRD와 실행 계획 분류하기 (중급)

다음 문장들이 PRD에 해당하는지, 실행 계획에 해당하는지 분류하세요.

A. "판매자로서, 상품 이미지를 쉽게 등록할 수 있다."
B. "POST /api/products API 엔드포인트를 개발한다."
C. "론칭 후 6개월 내 활성 스토어 100개 확보"
D. "Backend는 Node.js + Express.js를 사용한다."
E. "모바일 우선 접근(Mobile-First)을 채택한다."
F. "Task 1, 2가 완료되어야 Task 5의 연동 테스트가 가능하다."

PRD        : A (사용자 스토리), C (성공 지표), E (디자인 원칙)
실행 계획  : B (기술적 태스크), D (기술 명세), F (의존성 정의)

문제 3: 실행 계획 태스크 의존성 설계하기 (심화)

다음은 "게시판 CRUD 기능"을 구현하기 위한 태스크 목록입니다. 올바른 의존성 순서와 병렬 가능한 태스크를 설계해보세요.

Task A: 게시글 목록 페이지 UI 컴포넌트 개발 (Frontend)
Task B: posts 테이블 스키마 설계 (DB)
Task C: GET /api/posts API 엔드포인트 개발 (Backend)
Task D: POST /api/posts API 엔드포인트 개발 (Backend)
Task E: 게시글 작성 폼 UI 컴포넌트 개발 (Frontend)
Task F: 프런트엔드-백엔드 연동 테스트 (Fullstack)

의존성 순서:
  Phase 1: Task B (DB 스키마) ← 모든 API의 기반
  Phase 2: Task C, Task D (병렬 가능 — 둘 다 B에만 의존)
  Phase 3: Task A, Task E (병렬 가능 — UI는 독립적으로 개발 가능,
           단 목데이터 사용)
  Phase 4: Task F (A+C, E+D 모두 완료 후 연동 테스트)

의존성 다이어그램:
  B ──→ C ──→ A ──→ F
   └──→ D ──→ E ──↗

병렬 가능한 조합:
  - C와 D (둘 다 B에만 의존)
  - A와 E (UI 컴포넌트는 목데이터로 독립 개발 가능)

부록 A — 용어 사전

부록 B — 비교표

PRD vs 실행 계획 종합 비교

PRD 작성 방법: 직접 작성 vs 클로드 활용

실행 계획 작성 4단계 프로세스

부록 C — 참고 자료